1 00:00:12,000 --> 00:00:14,001 Hi, I'm Paul KB5MU. 2 00:00:15,000 --> 00:00:18,000 I'm here to propose a method for user authentic 3 00:01:12,001 --> 00:01:14,001 [...] amateur satellites. 4 00:01:16,001 --> 00:01:22,000 Amateur radio has been using satellites since late 1961, and the technology 5 00:01:22,000 --> 00:01:23,001 has been constantly evolving. 6 00:01:25,000 --> 00:01:28,000 Except for the recent profusion of single channel FM 7 00:01:28,000 --> 00:01:29,001 satellites, the trend has been changing over the years. 8 00:01:34,000 --> 00:01:40,001 The next big step forward is to replace the linear transponders with high 9 00:01:40,001 --> 00:01:43,000 performance digital payloads. 10 00:01:43,001 --> 00:01:47,001 Open Research Institute has been working on a design for a digital satellite 11 00:01:47,001 --> 00:01:53,001 communication system called P4XT that uses many individual digital uplink 12 00:01:53,001 --> 00:01:59,001 channels in the 5GHz microwave band, an onboard multiplexer, and a single 13 00:01:59,001 --> 00:02:06,000 broadband DBBS2 or S2X digital downlink in the 10GHz microwave band. 14 00:02:06,001 --> 00:02:12,000 It will support many simultaneous real-time voice users, as well as a range of 15 00:02:12,000 --> 00:02:15,000 capabilities for both higher and lower bandwidth communications. 16 00:02:16,000 --> 00:02:20,001 The system is designed for a geostationary orbit, or for a high elliptical orbit. 17 00:02:21,000 --> 00:02:24,001 It can also be used terrestrially with a central station or ground sat 18 00:02:24,001 --> 00:02:26,000 in a prime location. 19 00:02:27,000 --> 00:02:32,001 It's our hope that this system will be affordable, easy to use, and very useful 20 00:02:32,001 --> 00:02:34,001 for actual communication between amateurs. 21 00:02:36,000 --> 00:02:40,000 Those characteristics will make the system popular with users, supporting a 22 00:02:40,000 --> 00:02:42,000 vibrant community of cooperating users. 23 00:02:43,001 --> 00:02:47,001 Unfortunately, a system like that may also attract various kinds of misbehavior. 24 00:02:48,001 --> 00:02:53,000 It might attract non-amateur users who wish to exploit the utility of the system. 25 00:02:54,000 --> 00:02:58,001 It might attract amateur users who disregard the rules and regulations and 26 00:02:58,001 --> 00:03:01,001 operating practices recommended by the satellite owner or operator. 27 00:03:03,000 --> 00:03:08,001 It might attract users with personal grudges against others who might seek to use 28 00:03:08,001 --> 00:03:11,001 the system for harassment or to deny use of the system to certain 29 00:03:11,001 --> 00:03:14,000 people, and so on. 30 00:03:14,001 --> 00:03:19,000 These types of misbehavior make the system less pleasant for the majority of 31 00:03:19,000 --> 00:03:24,000 cooperating users and can damage the reputation of the system and of the amateur 32 00:03:24,000 --> 00:03:26,000 radio and amateur satellite services as a whole. 33 00:03:27,001 --> 00:03:29,000 These risks are not imaginary. 34 00:03:30,000 --> 00:03:33,001 The amateur satellite service hasn't yet flown a system that was useful enough 35 00:03:33,001 --> 00:03:39,001 and easy enough to attract widespread pirate usage, but the US Navy FleetSat-com 36 00:03:39,001 --> 00:03:45,001 satellites from the late 1970s and 1980s have seen extensive pirate use. 37 00:03:45,001 --> 00:03:51,000 It was possible to buy the components of a pirate FleetSat-com terminal at any 38 00:03:51,000 --> 00:03:54,001 truck stop in Brazil, and non-military communications 39 00:03:54,001 --> 00:03:56,000 could often be hard on the downlink. 40 00:03:57,000 --> 00:04:01,001 Because the system was a bent pipe analog transponder, there was little the Navy 41 00:04:01,001 --> 00:04:05,001 could do about pirate users operating outside US jurisdiction. 42 00:04:07,000 --> 00:04:11,001 For examples of smaller scale abuse by individual users, we need only look to 43 00:04:11,001 --> 00:04:14,001 decades of experience with terrestrial FM repeaters. 44 00:04:15,000 --> 00:04:20,000 Most have well-behaved user communities, and the occasional misbehavior is 45 00:04:20,000 --> 00:04:23,001 readily discouraged by peer pressure or by merely ignoring it. 46 00:04:24,000 --> 00:04:28,000 But notoriously, there are other repeaters where misbehavior is quite 47 00:04:28,000 --> 00:04:29,001 common and out of control. 48 00:04:30,001 --> 00:04:34,000 The repeater owner's only recourse is to turn the system off. 49 00:04:35,000 --> 00:04:38,001 We also see misbehavior on HF bands, which can't be turned off. 50 00:04:39,001 --> 00:04:42,001 There's just no way to ban persistent abusers. 51 00:04:44,000 --> 00:04:48,000 Once we move to a fully digital system, though, it becomes possible to do better. 52 00:04:49,000 --> 00:04:53,001 If we are able to identify the origin of every transmission, then misbehaving 53 00:04:53,001 --> 00:04:55,000 operators can be held accountable. 54 00:04:56,001 --> 00:04:59,000 Just knowing that their identities are public might be 55 00:04:59,000 --> 00:05:00,001 enough to discourage most of them. 56 00:05:01,001 --> 00:05:06,001 If they persist in misbehaving, the system can deny them access, which eliminates 57 00:05:06,001 --> 00:05:09,001 most of their ability to damage the system and the community. 58 00:05:10,001 --> 00:05:13,001 Ignoring the thousands of other things that can go wrong with a satellite 59 00:05:13,001 --> 00:05:18,001 communication system – space is hard – we will concentrate on problems that can 60 00:05:18,001 --> 00:05:20,001 be caused by radio signals on the uplink. 61 00:05:22,000 --> 00:05:24,001 We can divide these up into two overlapping classes. 62 00:05:25,000 --> 00:05:27,000 Let's call them jammers and abusers. 63 00:05:28,000 --> 00:05:33,000 A jammer transmits an especially strong signal, with the intent of preventing the 64 00:05:33,000 --> 00:05:34,001 desired signals from being received. 65 00:05:35,000 --> 00:05:40,000 An abuser, on the other hand, transmits a signal that resembles a desired signal, 66 00:05:40,001 --> 00:05:43,000 with the intention of using the system in a way 67 00:05:43,000 --> 00:05:44,001 not intended by the satellite owner. 68 00:05:46,001 --> 00:05:51,000 A pure jammer is a brute force attack, aimed at denial of service. 69 00:05:52,000 --> 00:05:56,000 There are tricks that can help defend against such attacks, but with enough 70 00:05:56,000 --> 00:05:58,001 power, the jammer can always defeat the receiver, 71 00:05:59,000 --> 00:06:00,001 no matter how cleverly designed. 72 00:06:01,001 --> 00:06:04,001 All radio communication systems have this fundamental vulnerability. 73 00:06:05,001 --> 00:06:08,000 A strong enough jammer can prevent communications from working. 74 00:06:09,000 --> 00:06:14,000 On the plus side, that strong jammer is pretty easy to detect and locate, so it 75 00:06:14,000 --> 00:06:16,000 can eventually be forced to shut down. 76 00:06:17,001 --> 00:06:21,000 Even better, there's usually no big incentive to simply jam a whole communication 77 00:06:21,000 --> 00:06:24,001 system, unless it's of military or political importance. 78 00:06:25,001 --> 00:06:27,001 We can't prevent a jamming attack. 79 00:06:27,001 --> 00:06:32,000 We can't expect that such attacks on our amateur satellite system will be 80 00:06:32,000 --> 00:06:35,000 infrequent, short in duration, limited in 81 00:06:35,000 --> 00:06:38,000 effectiveness, and risky for the jammer. 82 00:06:39,000 --> 00:06:40,001 At least, we have to hope so. 83 00:06:43,001 --> 00:06:45,000 Abuse attacks are another matter. 84 00:06:45,001 --> 00:06:50,000 The abusing station is technically very similar to an ordinary user station, at 85 00:06:50,000 --> 00:06:53,001 least in terms of basic performance, antenna size, power amplifier, and so on. 86 00:06:54,001 --> 00:06:59,000 We want user stations to be affordable, available, and easy to use, which means 87 00:06:59,000 --> 00:07:02,000 that the potential abusers also have ready access to the equipment. 88 00:07:03,000 --> 00:07:07,001 The potential abuser doesn't need to emit any particularly loud signals, so it 89 00:07:07,001 --> 00:07:10,000 can hide among all the ordinary users and evade detection. 90 00:07:11,001 --> 00:07:16,000 Perhaps worst of all, in some cases there can be a strong incentive to abuse the 91 00:07:16,000 --> 00:07:20,001 system, as in the case of that Navy FleetSat-COM system I described earlier. 92 00:07:22,000 --> 00:07:27,000 We have not seen this kind of large-scale abuse on amateur satellites so far, 93 00:07:27,001 --> 00:07:30,001 probably because our systems have not reached the threshold of usefulness 94 00:07:30,001 --> 00:07:32,000 to attract pirate users. 95 00:07:33,000 --> 00:07:35,001 Maybe a P4 XT system will cross that threshold. 96 00:07:37,000 --> 00:07:41,000 What we have already seen on a large scale is accidental intruders interfering 97 00:07:41,000 --> 00:07:43,000 with satellite uplink frequencies. 98 00:07:43,001 --> 00:07:49,000 For example, on Oscar 13's Mode B linear transponder, it was pretty common to 99 00:07:49,000 --> 00:07:51,001 hear taxi dispatch traffic from Central America. 100 00:07:52,001 --> 00:07:55,000 Nothing could be done to reduce this clutter on the downlink. 101 00:07:57,000 --> 00:08:01,000 Any kind of regenerating digital transponder solves that problem right away. 102 00:08:01,001 --> 00:08:04,001 If a signal doesn't match the kind of signal the satellite is intended to 103 00:08:04,001 --> 00:08:09,000 receive, it gets filtered out and cannot accidentally appear on the downlink. 104 00:08:10,001 --> 00:08:12,001 So we have narrowed down the problem quite a bit. 105 00:08:13,000 --> 00:08:16,001 The only ground stations that can really disrupt the orderly operation of the 106 00:08:16,001 --> 00:08:21,000 system short of brute force jamming are stations that accurately mimic the 107 00:08:21,000 --> 00:08:23,000 characteristics of a normal user uplink. 108 00:08:24,000 --> 00:08:28,000 This is similar to the situation we have today on terrestrial FM repeaters. 109 00:08:29,000 --> 00:08:34,001 What we need is a way to unambiguously identify the source of any transmission. 110 00:08:36,000 --> 00:08:41,001 On digital voice systems based on LAN mobile technologies like DSTAR or DMR, each 111 00:08:41,001 --> 00:08:46,000 station is configured to transmit identification automatically, and unidentified 112 00:08:46,000 --> 00:08:47,001 transmissions are invalid. 113 00:08:49,000 --> 00:08:51,001 But there's nothing stopping an abuser from entering a false identity. 114 00:08:52,001 --> 00:08:56,001 We need to add a way to definitely tie each use of a call sign 115 00:08:56,001 --> 00:08:58,001 to its actual licensee. 116 00:08:59,001 --> 00:09:03,001 This problem is very similar to well-known security issues that arise on the 117 00:09:03,001 --> 00:09:07,000 internet, and standard cryptographically secure techniques exist 118 00:09:07,000 --> 00:09:09,000 that can be used to solve it. 119 00:09:10,000 --> 00:09:15,000 We propose a specific system designed for authentication of users on the uplink 120 00:09:15,000 --> 00:09:17,001 to the P4XT digital transponder. 121 00:09:19,001 --> 00:09:23,000 The design of this system is constrained by the rules and regulations 122 00:09:23,000 --> 00:09:24,001 in the Amateur Satellite Service. 123 00:09:26,000 --> 00:09:29,001 Under the United States rules enforced by the Federal Communications Commission, 124 00:09:30,000 --> 00:09:36,001 the FCC, no amateur station shall transmit messages encoded for the purpose 125 00:09:36,001 --> 00:09:40,001 of obscuring their meaning, except as otherwise provided herein. 126 00:09:42,000 --> 00:09:45,001 That is to say, we're not allowed to encrypt the contents of our messages. 127 00:09:46,001 --> 00:09:50,000 There is nothing in the FCC rules that prohibits the use of cryptographic 128 00:09:50,000 --> 00:09:54,001 techniques for other purposes, such as authenticating amateur uplinks. 129 00:09:55,000 --> 00:09:58,000 We just have to be careful not to encrypt any message data. 130 00:09:59,000 --> 00:10:01,000 Other countries have similar rules. 131 00:10:02,000 --> 00:10:04,001 Some countries may have much stricter rules. 132 00:10:05,000 --> 00:10:08,001 It may not be legal to use the proposed system in such countries without a 133 00:10:08,001 --> 00:10:10,000 special waiver or rules change. 134 00:10:12,000 --> 00:10:16,000 The design is further constrained by the need to be fairly efficient in terms 135 00:10:16,000 --> 00:10:17,001 of uplink resources used. 136 00:10:18,000 --> 00:10:23,000 We will need to add some authentication data to every uplink transmission, but 137 00:10:23,000 --> 00:10:26,000 that overhead needs to be kept pretty small in order to avoid 138 00:10:26,000 --> 00:10:27,001 wasting too much uplink bandwidth. 139 00:10:28,001 --> 00:10:32,000 It turns out we will also need to occasionally perform an exchange of larger 140 00:10:32,000 --> 00:10:35,000 authentication messages between the ground station and the satellite. 141 00:10:36,000 --> 00:10:39,000 Those transactions can't occur too often, again, because of efficiency. 142 00:10:40,000 --> 00:10:44,001 The rate at which the authentication transactions take place needs to be under 143 00:10:44,001 --> 00:10:48,001 the control of the satellite, since the satellite has to handle a large number of 144 00:10:48,001 --> 00:10:52,000 simultaneous users and has limited onboard resources 145 00:10:52,000 --> 00:10:53,001 for storage and for computation. 146 00:10:56,000 --> 00:11:02,000 And we assume, for the purposes of this design, that policy decisions governing 147 00:11:02,000 --> 00:11:06,001 uplink authentication are made by the entity that owns or operates the satellite. 148 00:11:08,000 --> 00:11:11,001 We hope that most systems can normally be operated in a very relaxed 149 00:11:11,001 --> 00:11:15,001 authentication mode, with any licensed amateur radio operator welcome 150 00:11:15,001 --> 00:11:17,000 to use the system at any time. 151 00:11:18,000 --> 00:11:22,001 We acknowledge that there may be periods of time, such as communications drills 152 00:11:22,001 --> 00:11:28,000 or emergencies, when it is desirable to limit the use of a satellite to a 153 00:11:28,000 --> 00:11:30,000 predetermined list of users. 154 00:11:31,000 --> 00:11:35,000 We have also designed the system to handle the case where the owner maintains a 155 00:11:35,000 --> 00:11:38,001 block list of stations that are not currently permitted to use the system. 156 00:11:39,001 --> 00:11:43,000 We leave the policy procedures up to the satellite owner to define. 157 00:11:43,000 --> 00:11:47,001 We just provide the mechanisms by which the users can be identified in real time, 158 00:11:48,000 --> 00:11:52,001 so that services can be provided or denied based on policy. 159 00:11:55,000 --> 00:11:59,001 Uplink transmissions on the P4 XT system are divided up into 40 millisecond 160 00:11:59,001 --> 00:12:03,000 frames, mainly because that's what works best for digital voice. 161 00:12:04,000 --> 00:12:08,000 Each time the ground station activates its transmitter, the first 40 millisecond 162 00:12:08,000 --> 00:12:12,001 frame is devoted to a fixed data pattern called a preamble, designed to be easy 163 00:12:12,001 --> 00:12:15,000 for the satellite to recognize and synchronize with. 164 00:12:15,001 --> 00:12:20,001 After that one preamble frame, every transmitted frame thereafter consists of a 165 00:12:20,001 --> 00:12:25,000 fixed synchronization word that marks the beginning of the frame, a short frame 166 00:12:25,000 --> 00:12:27,001 header, and a fixed number of payload bytes. 167 00:12:28,001 --> 00:12:33,001 The frame header contains the claimed identity of the ground station, which may 168 00:12:33,001 --> 00:12:40,000 be a plain callsign like KB5MU, or a decorated callsign such as KB5MU 169 00:12:40,000 --> 00:12:45,000 -15, or actually anything that fits into nine uppercase letters, 170 00:12:45,001 --> 00:12:47,000 digits, and a few punctuation marks. 171 00:12:48,001 --> 00:12:52,000 The header also contains other fields pertaining to the P4 XT uplink. 172 00:12:53,000 --> 00:12:57,001 The header is heavily encoded using a Golay code, so it's quite robust 173 00:12:57,001 --> 00:12:59,000 and usually received without errors. 174 00:13:00,000 --> 00:13:04,000 We extend the frame header by three bytes to make room for 175 00:13:04,000 --> 00:13:05,001 an authentication token. 176 00:13:07,000 --> 00:13:11,001 An authentication token is a meaningless number, not part of any message. 177 00:13:12,001 --> 00:13:16,001 The ground station creates the token and inserts it into the uplink frame header. 178 00:13:18,000 --> 00:13:22,000 When the satellite wishes to check the authenticity of the uplink, it extracts 179 00:13:22,000 --> 00:13:24,000 the token from the frame header and checks it. 180 00:13:24,001 --> 00:13:29,000 It's important that the ground station and the satellite can both compute the 181 00:13:29,000 --> 00:13:32,001 same token values, and that nobody else can do so. 182 00:13:33,001 --> 00:13:37,000 Anybody who is able to come up with a valid token value for another ground 183 00:13:37,000 --> 00:13:41,000 station will be able to impersonate that ground station, for however long 184 00:13:41,000 --> 00:13:42,001 that token value is valid. 185 00:13:43,001 --> 00:13:47,000 So we want the token to be valid for only a very short period of time, so that it 186 00:13:47,000 --> 00:13:50,001 would be impersonated or can't just intercept the token being transmitted on the 187 00:13:50,001 --> 00:13:52,001 uplink and reuse it. 188 00:13:54,000 --> 00:13:56,000 That would be the token value would change for every frame. 189 00:13:56,001 --> 00:14:00,001 So we need a method that allows the ground station to generate an endless stream 190 00:14:00,001 --> 00:14:02,001 of unpredictable, random looking numbers. 191 00:14:03,000 --> 00:14:06,000 And we need the satellite to be able to generate exactly the same stream of 192 00:14:06,000 --> 00:14:08,000 numbers, and we need it to be practically 193 00:14:08,000 --> 00:14:09,001 impossible for anyone else to do the same. 194 00:14:10,001 --> 00:14:13,001 We also need to be sure that the sequence of numbers never repeats. 195 00:14:15,000 --> 00:14:19,000 Okay, this is a familiar problem, and it's solved by a cryptographic protocol 196 00:14:19,000 --> 00:14:23,000 called Time-Based One-Time Password, or TOTP. 197 00:14:24,000 --> 00:14:28,001 This is the same thing used by apps like Google Authenticator, or by those little 198 00:14:28,001 --> 00:14:33,000 keychain gadgets that display a different six digit number every 30 seconds, used 199 00:14:33,000 --> 00:14:34,001 for two-factor authentication online. 200 00:14:36,000 --> 00:14:39,001 I'm not going to try to explain the math, but here's how it 201 00:14:39,001 --> 00:14:41,000 works at a block diagram level. 202 00:14:42,000 --> 00:14:44,001 We have a cryptographic computation called a hash function. 203 00:14:45,001 --> 00:14:50,000 A hash function takes some number of input bits, and generates a fixed number of 204 00:14:50,000 --> 00:14:53,000 output bits that depends only on the input bits. 205 00:14:54,000 --> 00:14:56,001 But in a complicated way that's practically impossible to reverse. 206 00:14:58,000 --> 00:15:01,000 There are standard accepted hash functions used for this kind of purpose, with 207 00:15:01,000 --> 00:15:03,001 names like SHA-1 and SHA-256. 208 00:15:05,001 --> 00:15:07,001 For input bits, we need at least two sources. 209 00:15:08,001 --> 00:15:10,000 One source is the date and time. 210 00:15:11,001 --> 00:15:14,000 The time changes with every frame, and time is always increasing, 211 00:15:14,001 --> 00:15:16,001 so we never get the same input twice. 212 00:15:17,001 --> 00:15:19,001 Time is, of course, well known to everybody. 213 00:15:20,000 --> 00:15:24,001 So we need an extra input, called a shared secret, which is known to the 214 00:15:24,001 --> 00:15:29,000 authentic ground station and to the satellite, but not known by anybody else. 215 00:15:31,000 --> 00:15:33,000 Where does this magical shared secret come from? 216 00:15:34,000 --> 00:15:36,000 It turns out this is also a standard problem. 217 00:15:36,001 --> 00:15:38,001 It may surprise you to learn that we can create this shared 218 00:15:38,001 --> 00:15:40,001 secret securely over the air. 219 00:15:42,000 --> 00:15:44,001 Among other advantages, this means we can replace 220 00:15:44,001 --> 00:15:46,001 the shared secret as often as we like. 221 00:15:48,000 --> 00:15:50,000 The standard methods for generating a shared 222 00:15:50,000 --> 00:15:51,001 secret are called key agreement protocols. 223 00:15:53,000 --> 00:15:57,000 The best known key agreement protocol is called Diffie-Hellman, after 224 00:15:57,000 --> 00:15:58,001 two of its brilliant inventors. 225 00:15:59,001 --> 00:16:03,000 If you're at all interested in cool math, and aren't familiar with Diffie 226 00:16:03,000 --> 00:16:04,001 -Hellman, you should go read up on it. 227 00:16:05,000 --> 00:16:06,001 I can't go into the math here. 228 00:16:07,001 --> 00:16:11,001 The essence is that each party generates a big random number, which it keeps 229 00:16:11,001 --> 00:16:14,001 secret, and then uses it to calculate a second number. 230 00:16:15,001 --> 00:16:18,001 The parties then exchange their respective results over the air. 231 00:16:20,000 --> 00:16:23,001 Somebody listening in can know both of these second numbers, but does 232 00:16:23,001 --> 00:16:25,001 not know the random number for either party. 233 00:16:27,000 --> 00:16:31,000 Each party combines the second number they received with the random number they 234 00:16:31,000 --> 00:16:33,000 kept secret to generate a third number. 235 00:16:34,000 --> 00:16:38,000 And the magic in the math is that the third number works out to be the same for 236 00:16:38,000 --> 00:16:41,000 both parties, and that third number is the shared secret. 237 00:16:42,000 --> 00:16:44,001 An eavesdropper cannot compute the third number. 238 00:16:46,000 --> 00:16:48,001 Neither party can control the contents of the shared secret, 239 00:16:49,000 --> 00:16:51,000 so it's not an encrypted message. 240 00:16:51,001 --> 00:16:53,000 No meaning has been obscured. 241 00:16:54,001 --> 00:16:59,000 Key agreement of this sort uses cryptographic methods, but it is not encryption, 242 00:16:59,001 --> 00:17:01,001 and not prohibited by the FCC rules. 243 00:17:03,000 --> 00:17:05,001 Okay, great. We're getting pretty close to a solution. 244 00:17:06,000 --> 00:17:08,000 We have a standard, well-trusted way to generate a shared 245 00:17:08,000 --> 00:17:10,000 secret, the Diffie-Hellman key agreement. 246 00:17:11,000 --> 00:17:16,000 And we have TOTP, a standard, well-trusted way to use that shared secret to 247 00:17:16,000 --> 00:17:18,000 generate one-time tokens for each uplink frame. 248 00:17:19,001 --> 00:17:21,001 We're still missing one essential ingredient. 249 00:17:23,000 --> 00:17:26,000 How do we know that the ground station is really who it says it is? 250 00:17:26,001 --> 00:17:29,001 In other words, how do we link a ground station to a 251 00:17:29,001 --> 00:17:31,000 particular real-world identity? 252 00:17:33,000 --> 00:17:37,000 Let's back up a minute. What do we mean by a real-world identity? 253 00:17:37,001 --> 00:17:43,000 This is really a policy question, so the answer depends on the desires of the 254 00:17:43,000 --> 00:17:46,000 satellite owner, and possibly on the choice of authentication 255 00:17:46,000 --> 00:17:47,001 mode in use at a given time. 256 00:17:49,000 --> 00:17:53,000 During a communications drill or emergency, for example, there may be a very 257 00:17:53,000 --> 00:17:57,001 specific list of stations that are authorized to use a satellite, and everybody 258 00:17:57,001 --> 00:18:00,000 else is blocked or restricted to certain kinds of use. 259 00:18:01,000 --> 00:18:05,001 In that case, what we mean by real-world identity is whatever sort of 260 00:18:05,001 --> 00:18:07,000 identification is used on that list. 261 00:18:08,000 --> 00:18:13,000 It might be a list of station call signs, but it could just as easily be a set of 262 00:18:13,000 --> 00:18:15,001 tactical identifiers that are specific to the served agency 263 00:18:15,001 --> 00:18:17,000 or to the specific drill. 264 00:18:18,000 --> 00:18:21,000 It's going to depend on what's needed for the situation at hand. 265 00:18:21,000 --> 00:18:25,001 For a more general amateur radio scenario, what we mean by real-world identity is 266 00:18:25,001 --> 00:18:27,001 almost certainly the amateur radio station call 267 00:18:27,001 --> 00:18:30,000 sign, held by a specific licensee. 268 00:18:31,000 --> 00:18:34,001 Call signs are handy. They're compact and globally unique. 269 00:18:35,001 --> 00:18:38,000 Everybody who can legally operate an amateur radio station 270 00:18:38,000 --> 00:18:39,001 has a station call sign. 271 00:18:40,001 --> 00:18:45,001 In case we need to impose accountability for misbehavior, the call sign is the 272 00:18:45,001 --> 00:18:49,000 best way to identify the individual involved, especially when a pattern of 273 00:18:49,000 --> 00:18:51,000 misbehavior calls for government involvement. 274 00:18:53,001 --> 00:18:58,001 In the United States, the FCC maintains a public database of call signs with the 275 00:18:58,001 --> 00:19:01,000 name of the licensee and a mailing address. 276 00:19:02,001 --> 00:19:07,001 The mailing address doesn't need to be the licensee's residence or the location 277 00:19:07,001 --> 00:19:12,000 of the station or any other particular address, but there is one requirement that 278 00:19:12,000 --> 00:19:17,001 does apply. The licensee must be able to receive mail at that address, and they 279 00:19:17,001 --> 00:19:19,000 can respond to correspondence from the FCC. 280 00:19:20,001 --> 00:19:24,000 The mailing address is the main thing that definitely ties 281 00:19:24,000 --> 00:19:25,001 the licensee to the license. 282 00:19:27,001 --> 00:19:32,000 Can you see where I'm going with this? Somebody has already dealt with these 283 00:19:32,000 --> 00:19:37,000 facts and solved the problem of authenticating amateur radio operators. 284 00:19:38,001 --> 00:19:43,001 Back around the year 2001, a group of amateurs was working on the problem of 285 00:19:43,001 --> 00:19:47,000 digitally authenticating amateur radio contact records. 286 00:19:48,000 --> 00:19:55,000 They called their project Trusted QSL, and they got the ARRL, the league, 287 00:19:55,001 --> 00:19:58,000 to adopt it for their Logbook of the World project. 288 00:19:59,001 --> 00:20:04,001 The Logbook of the World is a way to confirm contacts for awards without 289 00:20:04,001 --> 00:20:06,001 physically exchanging QSL cards. 290 00:20:07,000 --> 00:20:11,001 Each participating operator uploads the list of contacts they've made, their 291 00:20:11,001 --> 00:20:16,000 Logbook, and the system searches for matches between uploaded logs. 292 00:20:16,001 --> 00:20:19,001 If both ends of a contact have reported matching information in their uploaded 293 00:20:19,001 --> 00:20:22,001 logs, both stations get credit for the contact. 294 00:20:24,000 --> 00:20:27,001 Some people were worried that a system like this might somehow be less 295 00:20:27,001 --> 00:20:32,000 trustworthy than a traditional system of manually checking QSL cards. 296 00:20:33,000 --> 00:20:37,001 To reassure those people, the Trusted QSL designers chose to use a powerful 297 00:20:37,001 --> 00:20:42,000 cryptographic technique called the Digital Signature Standard to make it 298 00:20:42,000 --> 00:20:45,001 practically impossible for a Logbook upload to be faked by any third party. 299 00:20:47,000 --> 00:20:53,001 Each operator submitting a Logbook upload uses special software called TQSL to 300 00:20:53,001 --> 00:20:56,000 apply a digital signature to the log file. 301 00:20:57,000 --> 00:20:59,000 The signature can only be created by the holder of the call 302 00:20:59,000 --> 00:21:00,001 sign used to make the contacts. 303 00:21:02,000 --> 00:21:06,000 The validity of the signature can be checked cryptographically, and any 304 00:21:06,000 --> 00:21:09,000 alteration to any of the Logbook data will invalidate the signature. 305 00:21:11,001 --> 00:21:15,000 This trick depends on a method called Public Key Cryptography. 306 00:21:16,000 --> 00:21:19,001 The user has a key that is kept secret, referred to as the Private Key. 307 00:21:21,000 --> 00:21:24,000 From the Private Key, they can derive a second key called the Public Key. 308 00:21:25,000 --> 00:21:28,000 As you might guess from the name, the Public Key can be shared with everyone 309 00:21:28,000 --> 00:21:30,001 without compromising the Private Key. 310 00:21:32,000 --> 00:21:34,001 The Key Pair can be used in a variety of ways. 311 00:21:35,001 --> 00:21:40,000 For digital signatures, the Private Key is used to compute a number, called the 312 00:21:40,000 --> 00:21:43,001 Signature, based on the contents of a message to be signed. 313 00:21:45,000 --> 00:21:48,001 Since the Private Key is kept secret, only the holder of the Key Pair is 314 00:21:48,001 --> 00:21:50,000 capable of computing the signature. 315 00:21:51,000 --> 00:21:56,001 But through the magic of the math, anyone with a copy of the Public Key is able 316 00:21:56,001 --> 00:21:59,001 to determine whether the signature is valid, and was 317 00:21:59,001 --> 00:22:01,000 made with the corresponding Private Key. 318 00:22:02,000 --> 00:22:07,001 This gives us a way to tie a message, such as a Logbook upload, to a specific 319 00:22:07,001 --> 00:22:10,001 Private Key without knowing the Private Key. 320 00:22:11,001 --> 00:22:15,001 But it still doesn't give us a way to know the real-world identity of the sender. 321 00:22:15,001 --> 00:22:19,000 The standard solution to this problem uses a digital 322 00:22:19,000 --> 00:22:20,001 document called a Certificate. 323 00:22:21,000 --> 00:22:26,000 The Certificate contains a user's Public Key, and some kind of identification 324 00:22:26,000 --> 00:22:27,001 information about that user. 325 00:22:28,001 --> 00:22:31,000 In the case of the Logbook of the World, it contains the user's call sign. 326 00:22:32,001 --> 00:22:37,000 The Certificate itself is then digitally signed by some authority. 327 00:22:38,000 --> 00:22:42,000 The signing authority may append its own certificate, which is digitally signed 328 00:22:42,000 --> 00:22:45,000 in turn by some higher authority, and so on. 329 00:22:46,000 --> 00:22:51,000 At the top of a chain is a Certificate from a Root Authority, which signs itself. 330 00:22:52,000 --> 00:22:57,000 This chain of trust relies on the Root Certificate being well known to all. 331 00:22:58,000 --> 00:23:02,000 In order to validate any Certificate from anywhere in the chain of trust, you 332 00:23:02,000 --> 00:23:04,001 only have to have a trusted copy of the Root Certificate. 333 00:23:06,000 --> 00:23:09,000 Any other Certificate in the hierarchy can be validated by checking the 334 00:23:09,000 --> 00:23:11,000 signatures up the chain to the root. 335 00:23:12,000 --> 00:23:15,000 For the Logbook of the World, there is a single trusted Root Certificate 336 00:23:15,000 --> 00:23:17,001 built into the TQSL software. 337 00:23:18,001 --> 00:23:23,000 The League uses that Root Certificate to sign a working Certificate, which is in 338 00:23:23,000 --> 00:23:27,000 turn used to sign a Certificate for each station that uses Logbook of the World. 339 00:23:28,000 --> 00:23:31,001 For this scheme to work, we have to trust that each authority in the chain of 340 00:23:31,001 --> 00:23:36,001 trust has done a good job of checking that it only signs authentic Certificates. 341 00:23:37,001 --> 00:23:41,001 For Logbook of the World, we trust that the League has kept the private key 342 00:23:41,001 --> 00:23:46,000 associated with its Root Certificate secret, and that the League only uses that 343 00:23:46,000 --> 00:23:51,001 private key to sign valid working Certificates, which it will in turn only use to 344 00:23:51,001 --> 00:23:55,000 sign Certificates for authentic amateur radio licensees 345 00:23:55,000 --> 00:23:57,000 for their legitimate call signs. 346 00:23:58,001 --> 00:24:00,001 So how does the League manage to do that? 347 00:24:00,001 --> 00:24:06,001 When a US licensee applies for a Logbook of the World Certificate, the League 348 00:24:06,001 --> 00:24:11,001 looks up their call sign in the FCC database and mails a postcard to the user 349 00:24:11,001 --> 00:24:13,001 at their official registered address. 350 00:24:14,001 --> 00:24:18,000 The postcard contains login information for a new Logbook of the World account, 351 00:24:18,001 --> 00:24:20,000 and the user can download their new 352 00:24:20,000 --> 00:24:22,000 Certificate and private key from that account. 353 00:24:23,000 --> 00:24:27,001 A postcard may not seem like top flight security at first glance, but remember 354 00:24:27,001 --> 00:24:32,000 that being able to receive mail at a particular mailing address is essentially 355 00:24:32,000 --> 00:24:35,000 the only fact the FCC knows for sure about a licensee. 356 00:24:36,000 --> 00:24:40,000 That postcard gives Logbook of the World the same level of assured authentication 357 00:24:40,000 --> 00:24:43,000 as the FCC licensing process itself. 358 00:24:44,001 --> 00:24:49,000 For non-US licensees, the League uses a slightly different procedure. The user is 359 00:24:49,000 --> 00:24:51,001 required to send in a copy of their license and identification. 360 00:24:53,000 --> 00:24:59,001 The League validates the proof visually using some criteria before approving the 361 00:24:59,001 --> 00:25:03,001 user's request for a call sign certificate. I don't know what criteria they 362 00:25:03,001 --> 00:25:05,000 use. I don't think they've been published. 363 00:25:06,001 --> 00:25:11,001 So what does the Logbook of the World have to do with us? Well, we need something 364 00:25:11,001 --> 00:25:16,001 exactly like their certificates to tie satellite ground stations to real 365 00:25:16,001 --> 00:25:18,001 world identities. Call signs. 366 00:25:20,000 --> 00:25:25,000 In fact, we might as well just use the certificates issued by ARRL's Logbook of 367 00:25:25,000 --> 00:25:28,000 the World. There is no need to duplicate this mechanism 368 00:25:28,000 --> 00:25:30,000 or to build a separate chain of trust. 369 00:25:31,000 --> 00:25:37,001 As of this writing, Logbook of the World has 232,000 active certificates 370 00:25:37,001 --> 00:25:41,001 issued to 162,000 users worldwide. 371 00:25:43,000 --> 00:25:47,000 That's not every amateur radio operator in the world, not by a long shot, but it 372 00:25:47,000 --> 00:25:50,000 probably includes a good percentage of the most active operators. 373 00:25:51,000 --> 00:25:54,001 I'm guessing that most people who would be early adopters of a P4 XT satellite 374 00:25:54,001 --> 00:25:56,001 system already have a certificate. 375 00:25:58,001 --> 00:26:02,001 We're not stuck using just one source of certificates either. If the Logbook of 376 00:26:02,001 --> 00:26:06,001 the World certificates can't be used by everybody for any reason, it wouldn't be 377 00:26:06,001 --> 00:26:10,001 too big a deal to establish our own route certificate and issue call sign 378 00:26:10,001 --> 00:26:14,000 certificates of our own in the same way the League does for Logbook of the World. 379 00:26:14,001 --> 00:26:20,001 If some entity ever wants to use our P4 XT system design outside of the amateur 380 00:26:20,001 --> 00:26:24,000 radio services, they could easily establish their own chain of trust 381 00:26:24,000 --> 00:26:26,000 based on something other than call signs. 382 00:26:27,000 --> 00:26:30,000 The certificate system is more than flexible enough to 383 00:26:30,000 --> 00:26:31,001 accommodate any likely use case. 384 00:26:33,001 --> 00:26:37,001 So, with the addition of call sign certificates to our Key Agreement Scheme and 385 00:26:37,001 --> 00:26:41,001 TOTP Frame Authentication Tokens, we have all the necessary mechanisms 386 00:26:41,001 --> 00:26:43,000 to implement user authentication. 387 00:26:44,000 --> 00:26:45,001 Let's take a look at how this will work. 388 00:26:47,000 --> 00:26:50,000 A user buys or builds a P4 XT ground station. 389 00:26:51,000 --> 00:26:54,001 As part of the initial setup procedure, they configure the ground station with 390 00:26:54,001 --> 00:26:56,001 their call sign certificate from Logbook of the World 391 00:26:56,001 --> 00:26:58,001 or some other accepted source. 392 00:26:59,001 --> 00:27:03,000 They also configure the ground station with the identity they wish to use on the 393 00:27:03,000 --> 00:27:06,001 air, which is probably also their call sign, but could be anything. 394 00:27:07,001 --> 00:27:09,001 We call it the claimed identity. 395 00:27:11,000 --> 00:27:15,000 Some other configurations probably needed so the ground station knows the basic 396 00:27:15,000 --> 00:27:18,001 parameters of the satellite, such as its downlink frequency and symbol rate. 397 00:27:20,000 --> 00:27:23,001 The user then aims the ground station antenna at the satellite and begins to 398 00:27:23,001 --> 00:27:28,000 receive the multiplex DBB S2 or S2X downlink from the satellite. 399 00:27:29,000 --> 00:27:32,000 The user can now listen to traffic on the satellite to their heart's content. 400 00:27:32,000 --> 00:27:36,001 The downlink contains not just user traffic, but also traffic generated by the 401 00:27:36,001 --> 00:27:39,001 satellite itself, including telemetry from the satellite 402 00:27:39,001 --> 00:27:41,001 and other information of general interest. 403 00:27:42,001 --> 00:27:46,000 It also includes a stream of control messages, including a few 404 00:27:46,000 --> 00:27:47,001 that pertain to user authentication. 405 00:27:49,000 --> 00:27:51,001 One of these is the auth broadcast message. 406 00:27:52,001 --> 00:27:55,001 It contains various parameters that all users need to participate 407 00:27:55,001 --> 00:27:57,000 in the authentication protocol. 408 00:27:57,001 --> 00:28:01,000 It's transmitted once per second so that a ground station won't have to wait very 409 00:28:01,000 --> 00:28:03,000 long to receive it when first powering up. 410 00:28:04,000 --> 00:28:08,000 It contains the date and time to 40 millisecond resolution so that the ground 411 00:28:08,000 --> 00:28:12,000 station clock will be in sync with the satellite's clock, which is necessary for 412 00:28:12,000 --> 00:28:14,000 the TOTP tokens to match up correctly. 413 00:28:15,000 --> 00:28:19,000 It contains a unique identifier for the satellite, just in case we someday 414 00:28:19,000 --> 00:28:20,001 have many satellites in the sky. 415 00:28:21,001 --> 00:28:25,000 It contains the public parameters for the Diffie-Hellman key agreement protocol, 416 00:28:25,001 --> 00:28:29,001 and it contains two values that define how many frames can be transmitted 417 00:28:29,001 --> 00:28:31,000 with the same authentication token. 418 00:28:32,001 --> 00:28:34,001 The ground station records these values for later use. 419 00:28:35,001 --> 00:28:39,000 When the ground station wishes to transmit, it simply starts to transmit. 420 00:28:40,000 --> 00:28:44,001 If it has stored authentication information from a previous session, it can use 421 00:28:44,001 --> 00:28:47,000 the old information to fill in authentication tokens for each frame. 422 00:28:48,000 --> 00:28:52,000 If it does not have such information, default values are used to create a 423 00:28:52,000 --> 00:28:53,001 stream of tokens to use in the meantime. 424 00:28:55,000 --> 00:28:57,001 The satellite will receive these frames and evaluate 425 00:28:57,001 --> 00:28:59,000 the authentication tokens in them. 426 00:29:00,000 --> 00:29:02,000 What it does next will depend on the policy 427 00:29:02,000 --> 00:29:03,001 decision set by the satellite operator. 428 00:29:05,000 --> 00:29:08,001 We hope that under normal conditions, the satellite would go ahead and retransmit 429 00:29:08,001 --> 00:29:12,001 these frames on the downlink, even if the authentication tokens don't check out. 430 00:29:13,000 --> 00:29:17,001 This policy would be the friendliest to users, and also minimize the delay in 431 00:29:17,001 --> 00:29:19,001 case the user has emergency traffic to transmit. 432 00:29:21,001 --> 00:29:26,001 Then, or sometime later, according to satellite policy, the satellite may decide 433 00:29:26,001 --> 00:29:28,001 it wants to authenticate the user. 434 00:29:29,000 --> 00:29:33,001 This may occur because the user's tokens didn't check out, or just because it's 435 00:29:33,001 --> 00:29:37,001 been a while since the user was less authenticated, or for any other reason 436 00:29:37,001 --> 00:29:39,000 as dictated by satellite policy. 437 00:29:40,001 --> 00:29:45,001 The satellite initiates an authentication transaction by transmitting a directed 438 00:29:45,001 --> 00:29:49,001 auth challenge message, containing the claimed identity found in the 439 00:29:49,001 --> 00:29:51,000 transmission it wishes to authenticate. 440 00:29:52,001 --> 00:29:57,001 It also contains an identifier for this authentication transaction, a block of 441 00:29:57,001 --> 00:30:02,000 random bits to add security to the transaction, and the satellite's computed 442 00:30:02,000 --> 00:30:04,001 value for the Diffie-Hellman Key Agreement protocol. 443 00:30:05,001 --> 00:30:09,001 Notice that we're doing multiple things in parallel here. We're starting the 444 00:30:09,001 --> 00:30:13,000 certificate check, but we're also going ahead with the Key Agreement protocol. 445 00:30:15,000 --> 00:30:18,000 The ground station receives this message and matches up the claimed identity 446 00:30:18,000 --> 00:30:23,000 field to its own, and begins to process the authentication transaction. 447 00:30:24,000 --> 00:30:28,000 It formulates a virtual message that will be signed using the secret key 448 00:30:28,000 --> 00:30:30,000 associated with its call sign certificate. 449 00:30:30,001 --> 00:30:34,001 Notice this virtual message is never actually transmitted by either station. 450 00:30:35,001 --> 00:30:40,000 The message echoes back the satellite identifier from the auth broadcast, and the 451 00:30:40,000 --> 00:30:44,000 claimed identity that was challenged in the directed auth challenge, along with 452 00:30:44,000 --> 00:30:45,001 the challenge bits from the message. 453 00:30:47,000 --> 00:30:52,000 The ground station supplies its actual identity, its call sign, which must match 454 00:30:52,000 --> 00:30:54,000 the identity embedded in its certificate. 455 00:30:55,000 --> 00:31:01,000 The ground station also supplies its own computed value for Key Agreement, and 456 00:31:01,000 --> 00:31:05,000 the number of times it intends to repeat authentication tokens, within the limits 457 00:31:05,000 --> 00:31:06,001 specified in the auth broadcast. 458 00:31:07,001 --> 00:31:11,000 The ground station then computes a signature for this virtual message. 459 00:31:12,000 --> 00:31:15,000 Now the ground station is ready to reply to the challenge 460 00:31:15,000 --> 00:31:16,001 with an auth response message. 461 00:31:16,001 --> 00:31:21,000 The auth response contains all the information the satellite doesn't already 462 00:31:21,000 --> 00:31:24,001 have, but needs to be able to reconstruct the virtual message. 463 00:31:25,001 --> 00:31:30,000 The challenged claimed identity, the actual identity, the challenge identifier, 464 00:31:31,001 --> 00:31:35,001 the ground station's computed value for Key Agreement, and the ground station's 465 00:31:35,001 --> 00:31:37,000 intended number of repeats for tokens. 466 00:31:38,001 --> 00:31:44,000 The ground station appends the signature it computed for the virtual message, and 467 00:31:44,000 --> 00:31:46,000 a copy of the ground station's certificate. 468 00:31:47,000 --> 00:31:51,001 The satellite is able to validate the certificate based on information contained 469 00:31:51,001 --> 00:31:55,001 in the certificate, tracing the chain of trust back to one of the root 470 00:31:55,001 --> 00:31:57,001 certificates that the satellite knows about. 471 00:31:58,001 --> 00:32:02,000 The certificate also gives the satellite the information it needs to check the 472 00:32:02,000 --> 00:32:04,000 signature computed on the virtual message. 473 00:32:05,000 --> 00:32:08,001 If everything checks out, the satellite can trust that everything 474 00:32:08,001 --> 00:32:10,000 is as it appears to be. 475 00:32:11,001 --> 00:32:16,001 The satellite then transmits an auth-ac message. This message contains both the 476 00:32:16,001 --> 00:32:18,001 claimed identity and the actual identity. 477 00:32:20,000 --> 00:32:24,001 Notice that means the ground station cannot be truly anonymous, even to other 478 00:32:24,001 --> 00:32:28,000 users, even if its claimed identity doesn't have any obvious 479 00:32:28,000 --> 00:32:29,001 relationship to its actual identity. 480 00:32:30,001 --> 00:32:34,001 Since any ground station can receive the auth-ac message and associate the 481 00:32:34,001 --> 00:32:36,000 actual identity with the claimed identity. 482 00:32:38,000 --> 00:32:40,001 The auth-ac message also informs the ground station of the 483 00:32:40,001 --> 00:32:42,001 result of its authentication transaction. 484 00:32:44,000 --> 00:32:49,000 If everything was accepted, the response is, welcome, and the ground station may 485 00:32:49,000 --> 00:32:51,001 continue transmitting. In other cases, the response 486 00:32:51,001 --> 00:32:53,000 might be one of these other values. 487 00:32:55,000 --> 00:32:58,001 If the ground station is authorized to continue transmitting, then the switchover 488 00:32:58,001 --> 00:33:01,000 time from the auth-ac comes into play. 489 00:33:01,000 --> 00:33:06,000 This identifies the specific frame where the ground station is supposed to switch 490 00:33:06,000 --> 00:33:10,001 over from using its old or default authentication tokens to using newly computed 491 00:33:10,001 --> 00:33:14,000 authentication tokens based on the shared secret agreed upon using 492 00:33:14,000 --> 00:33:15,001 the Diffie-Hellman Key Agreement protocol. 493 00:33:16,001 --> 00:33:20,001 So there's no ambiguity. The ground station and the satellite both know exactly 494 00:33:20,001 --> 00:33:23,000 what's supposed to go in the authentication token of every frame. 495 00:33:23,000 --> 00:33:28,000 If the tokens don't match, the satellite can treat that as evidence that 496 00:33:28,000 --> 00:33:29,001 the ground station is not authentic. 497 00:33:31,000 --> 00:33:35,000 What it does then depends on policy, but it might well stop re-transmitting 498 00:33:35,000 --> 00:33:38,000 traffic from that ground station and log an authentication error. 499 00:33:39,001 --> 00:33:42,000 It's worth mentioning here that the satellite never re-transmits the 500 00:33:42,000 --> 00:33:46,000 authentication tokens. They're of no use to other ground stations, and re 501 00:33:46,000 --> 00:33:49,001 -transmitting them might cause a sneaky side-channel for encrypted communications. 502 00:33:51,000 --> 00:33:55,001 Once the auth-ac has been received and the switchover time has arrived, the 503 00:33:55,001 --> 00:33:57,000 ground station generates authentication tokens. 504 00:33:58,000 --> 00:34:01,000 The date, time, and the shared secret from the Diffie-Hellman Key Agreement 505 00:34:01,000 --> 00:34:04,000 protocol go into a SHA-1 hash function. 506 00:34:04,001 --> 00:34:09,001 The hash function computes a 160-bit number. An additional calculation is used 507 00:34:09,001 --> 00:34:11,000 to extract a smaller number. 508 00:34:12,001 --> 00:34:17,001 In vanilla TOTP, this is the six-digit passcode the user would read off the 509 00:34:17,001 --> 00:34:20,001 hardware token and type in to authenticate a login. 510 00:34:21,000 --> 00:34:25,001 For our application, we use this number as the authentication token for a frame 511 00:34:25,001 --> 00:34:27,001 or a short sequence of consecutive frames. 512 00:34:29,001 --> 00:34:33,001 It would probably be possible to customize this calculation for our purposes and 513 00:34:33,001 --> 00:34:35,001 come up with something more efficient than running the entire 514 00:34:35,001 --> 00:34:37,000 hash function for every frame. 515 00:34:38,000 --> 00:34:43,001 However, when mucking about with cryptographic protocols, it's notoriously easy 516 00:34:43,001 --> 00:34:47,000 to make a subtle little mistake and destroy the security of the protocol. 517 00:34:48,001 --> 00:34:52,001 Since we're not expert cryptographers, it's safer to just use an existing well 518 00:34:52,001 --> 00:34:56,000 -accepted protocol without modifications, to the extent possible. 519 00:34:56,001 --> 00:35:00,001 We presented this poster of our authentication scheme at the hacker convention, 520 00:35:01,000 --> 00:35:05,000 DEF CON 30, a few weeks ago, and asked the hackers for advice. 521 00:35:05,001 --> 00:35:11,000 We received some excellent feedback from Kate Gray, W9KAT, pointing out a 522 00:35:11,000 --> 00:35:14,001 possible security blunder we had made in modifying TOTP. 523 00:35:15,001 --> 00:35:20,000 Using TOTP unmodified is definitely safer, and that's the current plan. 524 00:35:22,000 --> 00:35:26,000 Kate also pointed out that with a minor change, we could have the authentication 525 00:35:26,000 --> 00:35:30,000 token protect the contents of the frame payload from modification. 526 00:35:31,000 --> 00:35:34,001 The token would authenticate not just the sender, but the message itself. 527 00:35:35,001 --> 00:35:37,000 We're still evaluating that suggestion. 528 00:35:39,001 --> 00:35:43,000 I've shown you a method by which the origin of every uplink transmission can be 529 00:35:43,000 --> 00:35:44,001 identified with high assurance. 530 00:35:45,001 --> 00:35:49,000 With this protocol in place, as part of the overall system protocol needed to 531 00:35:49,000 --> 00:35:54,000 access and use the P4 XT satellite, the satellite operator will have the ability 532 00:35:54,000 --> 00:35:59,000 to control access to the system and impose accountability on misbehaving users. 533 00:36:00,001 --> 00:36:04,000 Except for the need to provide a call sign certificate to the ground station 534 00:36:04,000 --> 00:36:07,001 controller, this imposes no burden on the individual user of a ground 535 00:36:07,001 --> 00:36:09,001 station. Everything is automatic. 536 00:36:10,001 --> 00:36:15,000 The burden on a satellite operator is also light, since the satellite itself can 537 00:36:15,000 --> 00:36:17,001 be programmed to implement the designated policy. 538 00:36:19,001 --> 00:36:24,000 A prototype implementation of the actual cryptographic calculations used in this 539 00:36:24,000 --> 00:36:26,001 design has been written in Python in a Jupyter notebook 540 00:36:26,001 --> 00:36:28,001 and benchmarked on a Raspberry Pi. 541 00:36:29,001 --> 00:36:33,000 This shows that the computations are not too burdensome for an embedded 542 00:36:33,000 --> 00:36:36,000 processor, such as might be used in a typical satellite design. 543 00:36:37,000 --> 00:36:40,001 That Jupyter notebook and other documents describing this authentication protocol 544 00:36:40,001 --> 00:36:44,000 can be found in our GitHub repository at this URL. 545 00:36:46,000 --> 00:36:50,001 This is still an early version of the design. Only the authentication protocol 546 00:36:50,001 --> 00:36:52,001 part has been fleshed out to even this level of detail. 547 00:36:52,001 --> 00:36:57,001 So there's still time for you to get involved and help out. 548 00:36:58,001 --> 00:37:03,000 Your comments and suggestions are sincerely welcomed. We do all our work out in 549 00:37:03,000 --> 00:37:08,001 the open, publishing as we go. Not just open source, but open process, too. 550 00:37:09,001 --> 00:37:13,001 If you're interested in helping out, please visit openresearch 551 00:37:13,001 --> 00:37:15,001 .institute and click on Getting Started. 552 00:37:16,001 --> 00:37:20,000 You don't have to be an expert, but you might accidentally become one. 553 00:37:20,000 --> 00:37:23,001 Thanks for listening. I'll try to answer any 554 00:37:23,001 --> 00:37:25,000 questions you may have in the time remaining. 555 00:37:41,000 --> 00:37:46,000 Hello. Please type any questions you may have into the chat 556 00:37:46,000 --> 00:37:48,000 and I'll do what I can to answer them. 557 00:37:50,000 --> 00:38:16,000 Thank you. 558 00:38:20,000 --> 00:38:21,000 No questions. 559 00:39:08,000 --> 00:39:11,000 I'm afraid this is not going to be a very lively Q&A session. 560 00:39:20,000 --> 00:39:50,000 Thank you. 561 00:40:12,000 --> 00:40:18,000 I see a question from Gary into AMC. Has this approach been discussed with AMSAT? 562 00:40:18,000 --> 00:40:21,001 Not in any kind of detail, no. 563 00:40:36,001 --> 00:40:40,000 And thank you, Gary, for proving that the comment system actually is working. 564 00:40:42,000 --> 00:40:45,000 Anybody else with questions, please type them in. 565 00:40:47,000 --> 00:40:52,001 Comments are welcome, too. 566 00:41:08,000 --> 00:41:12,000 Jeffrey asked, can you describe the P4 XT transponder a bit more 567 00:41:12,000 --> 00:41:13,001 as to what it is and what it does? 568 00:41:14,000 --> 00:41:15,000 [...] 569 00:41:18,001 --> 00:41:22,000 The P4 XT transponder is a fully digital transponder, so 570 00:41:22,000 --> 00:41:24,000 uplinks and downlinks are both digital. 571 00:41:25,000 --> 00:41:30,001 The downlink is based on a very standard and very state-of-the-art 572 00:41:30,001 --> 00:41:34,001 modulation and protocol called 573 00:41:34,001 --> 00:41:38,001 DBBS2S2X, an extended version of that. 574 00:41:38,001 --> 00:41:44,001 This is one big pipe coming down from the satellite with every user's 575 00:41:44,001 --> 00:41:49,001 traffic and anything else that the satellite may wish to transmit all multiplex 576 00:41:49,001 --> 00:41:55,000 into one transmission, so every user can conceptually receive everything. 577 00:41:56,000 --> 00:41:58,001 And then on the uplink, individual channels are allocated. 578 00:41:59,000 --> 00:42:05,001 Sort of the baseline communication would be voice, so a channel 579 00:42:05,001 --> 00:42:12,000 wide enough to carry a high-quality digital voice, see my next talk, will 580 00:42:12,000 --> 00:42:14,001 be transmitted on the uplink. 581 00:42:14,001 --> 00:42:21,000 And then the satellite itself will do the multiplexing automatically, receiving 582 00:42:21,000 --> 00:42:26,000 whatever comes up on the uplinks and authenticating them, as described here in 583 00:42:26,000 --> 00:42:29,001 this talk, and prioritizing them if necessary 584 00:42:29,001 --> 00:42:31,001 and transmitting them on the downlink. 585 00:42:32,001 --> 00:42:34,001 Voice is not the only thing that can be used for, of course, it can be used for 586 00:42:34,001 --> 00:42:40,001 data or higher speed communications up to some limit, depending on how large 587 00:42:40,001 --> 00:42:42,001 the user's ground station is. 588 00:42:43,000 --> 00:42:49,001 That is the basic idea. It's intended to be used in a geostationary orbit. You 589 00:42:49,001 --> 00:42:54,000 may have to compromise and use it in a high orbit, either an elliptical one or a 590 00:42:54,000 --> 00:42:58,001 graveyard orbit near geostationary, but not exactly geostationary. 591 00:42:59,001 --> 00:43:05,000 And we also intend for it to be usable on the ground. You could put a ground sat 592 00:43:05,000 --> 00:43:10,000 or a satellite simulator sort of device on a tower, on a tall building, or a 593 00:43:10,000 --> 00:43:15,000 mount and top if you're so blessed in your area, and do the same sorts of thing. 594 00:43:17,001 --> 00:43:22,000 I think that pretty much covers the basics of it. Your next question would 595 00:43:22,000 --> 00:43:27,001 probably be when, we don't know, what launch, we don't know. 596 00:43:27,001 --> 00:43:32,001 Who's going to pay for it? That's also a problem. Like a lot of ambitious 597 00:43:32,001 --> 00:43:39,000 projects, this is going to have to rely on some luck and some 598 00:43:39,000 --> 00:43:43,001 wrangling, and we have not yet gotten there. 599 00:43:54,001 --> 00:43:59,001 Gary asked a follow-up question. Do you intend to discuss it with them, AMSAT? If 600 00:43:59,001 --> 00:44:02,001 AMSAT is involved in the project at some point, 601 00:44:03,001 --> 00:44:05,001 we will, of course, discuss it with them. 602 00:44:06,000 --> 00:44:13,000 AMSAT has not shown a lot of interest in our project, except 603 00:44:13,000 --> 00:44:18,000 negatively. So for the time being, we've not been discussing this with AMSAT. 604 00:44:27,001 --> 00:44:30,000 That's all the questions I've seen so far, so type in more. 605 00:44:32,000 --> 00:44:32,001 Thank you, Jeffrey. 606 00:44:40,000 --> 00:44:46,000 You can join mailing lists, Slack channel, watch the GitHub. 607 00:44:47,001 --> 00:44:50,000 There are many different ways to keep track of what we're doing. We're completely 608 00:44:50,000 --> 00:44:52,000 open and transparent about everything we're doing. 609 00:44:53,001 --> 00:44:54,001 That's a goal anyway. 610 00:45:11,000 --> 00:45:13,001 That doesn't need to be responded to here. 611 00:45:38,001 --> 00:45:41,001 Thank you, Gary. 612 00:46:08,001 --> 00:46:15,000 I'm not seeing any new comments coming in. While we've got a Slack 613 00:46:15,000 --> 00:46:19,001 minute here, I will thank Eric KF0-AMA, who is serving as host for this 614 00:46:19,001 --> 00:46:23,000 presentation. Thanks for your help. 615 00:46:58,000 --> 00:47:02,000 Well, what do you think, Eric? Should we call it? 616 00:47:08,001 --> 00:47:11,001 You're not on screen until I can't hear you. 617 00:47:17,000 --> 00:47:18,001 Yeah, we can go ahead and call it. 618 00:47:20,000 --> 00:47:23,000 Okay, well, thank you all for your attention. If you have any questions that you 619 00:47:23,000 --> 00:47:28,000 didn't get into the chat for whatever reason, get ahold of me. You 620 00:47:28,000 --> 00:47:30,000 can find me at Open Research at that [...] 621 00:47:32,000 --> 00:47:36,000 Lots of other places as well. So thanks for your attention and 622 00:47:36,000 --> 00:47:38,000 enjoy the rest of HamExpo.